Flexibly Integrating Endpoint Logic Into Varied Platforms

ABSTRACT

In one embodiment, the present invention is directed to an integrated endpoint having a virtual port coupled between an upstream fabric and an integrated device fabric that includes a multi-function logic to handle various functions for one or more intellectual property (IP) blocks coupled to the integrated device fabric. The integrated device fabric has a primary channel to communicate data and command information between the IP block and the upstream fabric and a sideband channel to communicate sideband information between the IP block and the multi-function logic. Other embodiments are described and claimed.

This application is a divisional of U.S. patent application Ser. No.12/415,470, filed Mar. 31, 2009, entitled “FLEXIBLY INTEGRATING ENDPOINTLOGIC INTO VARIED PLATFORMS,” the content of which is herebyincorporated by reference.

BACKGROUND

Mainstream processor chips, both in high performance and low powersegments, are increasingly integrating additional functionality such asgraphics, display engines, security engines, PCIe™ ports (i.e., ports inaccordance with the Peripheral Component Interconnect Express (PCIExpress™ (PCIe™)) Specification Base Specification version 2.0(published Jan. 17, 2007) (hereafter the PCIe™ specification) and otherPCI-e™ based peripheral devices.

Traditional peripheral hub product designs are highly segmented due tovarying requirements from the server, desktop, mobile, embedded,ultra-mobile and mobile Internet device segments. Different markets seekto use single chip system-on-chip (SoC) solutions that combine at leastsome of processor cores, memory controller hub (MCH), input/outputcontroller (ICH) and other segment specific acceleration elements onto asingle chip. However, designs that accumulate these features are slow toemerge due to the difficulty of integrating different intellectualproperty (IP) blocks on a single die to standard internal interconnects.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a block diagram of an integrated endpoint and virtual port inaccordance with an embodiment of the present invention.

FIG. 2 is a block diagram of an integrated endpoint and virtual port inaccordance with one embodiment of the present invention.

FIG. 3 is a block diagram of a system-on-chip (SoC) in accordance withone embodiment of the present invention.

FIG. 4 is a block diagram of a system in accordance with an embodimentof the present invention.

FIG. 5 is a flow diagram of a method in accordance with one embodimentof the present invention.

FIG. 6 is a flow diagram of a method for handling incoming messages fromcoupled agents in accordance with one embodiment of the presentinvention.

DETAILED DESCRIPTION

In various embodiments, interface functionality of a PCIe™ endpoint canbe segmented between fabric logic and an agent such as an intellectualproperty (IP) block or other logic block configured to perform one ormore functions, to enable efficient re-use of the agent across variousplatforms. As used herein, the terms “agent” and “IP block” may besynonymous to denote an independent logic that can be adapted within asemiconductor device along with other such agents, where the agents canoriginate with one or more vendors. For one implementation, such anagent can be implemented on-chip along with a virtual downstream port(root port or switch port) which may be a separate PCIe™ device, anintegrated device fabric (IDF) containing multi-function (MF) logic, andone or more agents, which each can implement one or more PCI-e™functions. In this way, one or more agents can be integrated into anon-die PCI-e™ device.

The virtual downstream port appears to software as a standard PCI-e™downstream port, however the link and physical layers are removed andreplaced with a master interface to communicate with an upstreamcomponent, e.g., a processor, and target interface to communicate withthe IDF. In one embodiment, the virtual downstream port includes a type1PCIe™ configuration header and associated virtual peer-to-peer bridgelogic. The virtual port appears to software as a “real” port, but thelink and physical layers are missing. Software can not tell thedifference. Various values for link and physical registers may be setwithin the virtual port such that software thinks the link and physicallayers are present. In turn, the IDF, MF logic and agents appear tosoftware as a PCI-e™ endpoint. Software can not tell that the endpointis not connected to the downstream port with a standard PCI-e™ link, asthe same functionality and information is presented. That is, thecombination of virtual port and IDF, MF logic and agents enablescomplete transparency to software such as a shrink-wrap operating system(OS). In addition, this interface is plug-and-play OS compatible andsupports various functions such as PCI plug-and-play enumeration and PCIordering, among other functions.

In one embodiment, the integrated device fabric is an implementation ofa fabric that contains MF logic. The MF logic provides the functionalitynecessary to enable separate agents designed to an interfacespecification to interoperate and appear to software as a standardPCI-e™ multi-function device, e.g., coupled via an off-chip (e.g.,PCIe™) link. This fabric provides the flow control, arbitration andordering logic. In addition, the multi-function logic supports variousfunctional requirements of a given standard. For example, in oneembodiment the MF logic may include logic to handle maximum payload sizein devices which support the Alternate Requester ID Interpretation(ARI), legacy interrupts, PCI power management (PM) messages,non-function specific errors, and latency tolerance reporting.

Coupled to this IDF may be one or more agents to implement one or morePCI-e™ functions. The agents can be integrated directly into a rootcomplex fabric or be connected below an integrated device fabric asdescribed below. The IDF in conjunction with the agents form anintegrated PCIe™ endpoint that can be connected to an integrated virtualport (root port or switch port).

Embodiments thus allow standard agents designed to an interfacespecification to be re-used between projects, either as functions withina multi-function device or as root complex integrated devices. There areno restrictions on the agents that limit them from implementing the fullfeature set of the PCI-e™ specification. By removing link and physicallayers and replacing the layers with a fabric, the need for variouslogic of such layers, e.g., cyclic redundancy checksum (CRC) and replaybuffers, is eliminated. This creates a lower latency, lower power,smaller design solution.

Re-use is enhanced by design rules to enable efficient partitioning oflogic between agent and fabric. A PCIe™ device typically has certainlogic that is common to the entire device and certain logic that isspecific to a function. Embodiments of the present invention define thepartitioning and implementation of what logic is situated in an agent(or one or more functions), and what logic is situated in the fabric (ordevice specific logic) to optimize the re-use across a wide variety ofplatforms. Part of the design goal is to enable the agent to be easilyused as part of a device that is integrated into different componentssuch as endpoints, fabrics and can be integrated inside or outside aroot complex. Thus certain functionality and complexity are includedinto the fabric because they are not needed when an agent is presentinside a root complex.

Referring now to FIG. 1, shown is a block diagram of an integratedendpoint connected to a virtual port which may be formed on a singlesemiconductor die in accordance with an embodiment of the presentinvention. As shown in FIG. 1, integrated endpoint 10 may include an IDF30 and one or more agents 50, and may be coupled to a virtual port 20,which may be a virtual root port or a virtual switch port, dependingupon the entity to which integrated endpoint 10 is coupled. For example,when coupled to a root complex fabric, virtual port 20 may be a virtualroot port, while instead when coupled to a switch fabric, virtual port20 may be a virtual switch port. In various embodiments, virtual port 20may be an architecturally visible register space, and may include a setof configuration registers for supporting plug-and-play and functiondiscovery. In turn, virtual port 20 is coupled to IDF 30 that includesmulti-function logic 35.

In turn, IDF 30 may be coupled to one or more agents 50 ₁-50 _(n). Eachsuch agent is an independent IP block and may be used to perform one ormore functions such as one or more PCI-e™ functions. In variousembodiments, in contrast to a conventional coupling of such agents via aPCI-e™ or other link, the integrated, i.e., on-die, coupling of agents50 to virtual port 20 may be realized by IDF 30. In this way, the needfor link and physical layers, both at virtual port 20 and agents 50 (andalso IDF 30) can be avoided. Instead virtual port 20 may communicatedirectly with IDF 30 at the transaction layer, and similarly IDF 30 maycommunicate directly with agents 50 at the transaction layer. Note thatthe agents as exemplified by agents 50 may be heterogeneous blocks ofone or more different vendors. For example, a SoC manufacturer mayinclude various agents in a single on-die solution that includes bothits own agents, as well as one or more agents of other vendors, e.g. toprovide or enhance certain functionality.

Referring now to FIG. 2, shown is a block diagram of an integratedendpoint 100 coupled to a virtual port. This integrated endpoint may besimilarly configured to that of FIG. 1. However, further details of IDF30 are presented. More specifically, as shown in FIG. 2, IDF 30 mayinclude multi-function logic 35 that includes a plurality independentlogics 40 a-40 d (for example) that can handle various functionalitythat enables interaction of different agents in integrated endpoint 100while maintaining visibility with system software (e.g., an operatingsystem). In the embodiment of FIG. 2, such logic includes registershadow logic 40 a, power management (PM) logic 40 b, legacy interruptlogic 40 c and error logic 40 d. While shown with these particular logicfunctionalities, the scope of the present invention is not limited inthis regard, and other logic may be present in MF logic 35. In addition,multi-function logic 35 includes a sideband endpoint 42 for coupling toa sideband router 50 via a sideband channel 62.

Still referring to FIG. 2, IDF 30 further includes arbiters both in theupstream and downstream directions (i.e., arbiters 48 _(a)-48 _(b)).Such arbiters may handle flow control and arbitration betweencommunications with the various agents, e.g., according to a credit flowcontrol and priority arbitration scheme. Arbiter 48 a and 48 b may checkthe resources of agents 50 to ensure there is space in the queues, andin the upstream direction it checks resources and arbitrates which agentcan have access to the upstream primary channel 49 b. In one embodiment,arbiter 48 a may act as a traffic cop for the command wires and operatein two phases. First a command is sent to the agents to perform targetdecode, i.e., it is broadcast to all agents. Then, the target agentresponds. As the arbiter now knows who the target is, next the arbiterchecks its resource availability, and once it determines that theresources are available, it can issue the grant and the actual commandand data are provided to the target agent.

Communication with agents 50 may occur via a primary channel 49, whichmay include separate links 49 _(a) and 49 _(b) in the downstream andupstream direction, respectively. In one embodiment, primary channel 49may have different wires present for command and data information. Asfurther seen, sideband router 60 may communicate with each agent 50 viaa given sideband channel 65 ₁-65 ₃. Note that peer-to-peercommunications between agents 50 are allowed, although not shown in FIG.2. While shown with this particular implementation in the embodiment ofFIG. 2, the scope of the present invention is not limited in thisregard.

In other implementations of an integrated device fabric, instead ofcoupling to agents in which all of the command and data widths are thesame, the fabric may perform queuing and staging to accept multipleclocking data and then widen it out, or vice versa. For ease ofillustration, no internal queuing is shown in FIG. 2, althoughembodiments may provide for such queuing. Further, while in someembodiments, downstream messages may be broadcast to all connectedagents, which perform a decode to determine whether a command is for thegiven agent, other embodiments may implement decoding in the IDF. Forexample, downstream queues may be present to accept transactions fromthe root port, which are then passed to an internal decoder to determinethe intended target.

An agent that implements one or more PCI-e™ functions may be integratedinto a root complex fabric, below a virtual root port as a portion of anintegrated device, or in a standalone PCI-e™ endpoint component. Inorder to enable re-use of an agent in these different systems, certainfunctionality is partitioned between the fabric and the agent, asdescribed above. In addition, protocols on how certain messages are sentthrough the IDF are established.

An integrated function is an agent which implements one or more PCIfunctions. These may be legacy PCI functions or PCIe™ compliantfunctions. Integrated functions that support the ARI may implement up to256 functions in one agent. Some embodiments may support single root IOvirtualization (SR-IOV), enabling up to 64 k functions within anintegrated function.

When connected to a root complex fabric, the functions within anintegrated function become a root complex integrated endpoint. Whenconnected to a switch fabric, the integrated functions are a part of amulti-function device that includes an upstream switch port. Whenconnected to an integrated device fabric, the integrated functions are apart of an integrated PCIe™ endpoint. Thus to maximize re-usability,integrated functions can be implemented such that they can connect to aroot complex fabric, a switch fabric or an integrated device fabric.Note that additional functionality when integrated functions are used tocreate a PCIe™ endpoint may be present.

Still referring to FIG. 2, legacy interrupt logic 42 c may be used tohandle agents that may generate PCI legacy interrupts. Agents whichimplement PCI or PCI-e™ compliant functions that generate interrupts arerequired by the PCI and PCI-e™ specifications to support legacyinterrupts. The destination for these legacy interrupts is aninput/output advanced programmable interrupt controller (IOxAPIC).Interrupt wires (i.e., legacy interrupt wires (INTx#)) are virtuallydelivered using messages. An Assert INTx# message indicates a high tolow transition of the virtual INTx# signal, while a DeAssert INTx#message indicates the low to high transition of the virtual INTx#signal.

In various embodiments, INTx messages can be delivered on both primaryand sideband message interfaces. To ensure interoperability of theagents the following rules are used for delivery of legacy interrupts.Agents that are the originating source of INTx messages (e.g., endpointor root port) will send them using sideband messages. Agents thatcontain more than one PCI/PCI-e™ function that share INTx virtual wireslogically OR the virtual wires together before sending theassert/de-assert messages. Agents that contain more than one PCI/PCI-e™function that do not share INTx virtual wires send the messages withdifferent sideband source IDs, enabling the receiver to differentiatethe source of the INTx message.

Legacy interrupt logic 40 c aggregates the legacy INTx messages that areshared by the agents below the fabric. The aggregated virtual INTx wirestate is then forwarded upstream on primary channel 49. Agents thatimplement a PCI-e™ root port will send legacy INTx messages on asideband channel targeting a local IOxAPIC.

PM logic 42 b may be used to provide support for PCI power management(PCI-PM). The following three messages may be used to handle powermanagement events, namely a power management event message, and similarturn off and turn off acknowledgment messages: PME, PME Turn Off (TO),and PME TO Ack. In one embodiment, the PCI-PM message contains a messagecode to indicate if the message is a PME, PME Turn Off, or PME TO Ack.The message also contains the bus, device and function number of themessage originator.

To support interoperability of agents that implement the PCI powermanagement capabilities, the following rules are used. Agents thatimplement the PCI-PM capability send PME messages, receive PME turn offmessages, and send PME TO Ack messages on the sideband messageinterface. In turn, IDF 30 provides the following functionality. First,the IDF receives PME Turn Off messages on the upstream primary interfaceand broadcasts them to any coupled agents that support PCI-PM (this maybe done as a true multicast, or as multiple unicast messages). Also, theIDF receives PME TO Ack messages over the sideband message interface,aggregates the messages and forwards a PME TO Ack message upstream onthe primary interface, and receives PME messages on the sideband messageinterface and forwards them upstream on the primary interface. Agentsthat implement PCI-e™ root ports receive PME Turn Off messages on thesideband message interface and forward them downstream on the primarychannel, and receive PME TO Ack messages from downstream (over an IDFfor virtual root ports, over PCI-e™ link for actual root ports) andforward PME TO Ack message on sideband message interface. Agents thatimplement a PCI-e™ root complex event collector will receive PMEmessages on the sideband message interface.

Error logic 40 d may provide support for PCI-e™ error messages, whichinclude the following three messages: error corrected (ERR CORR), errornon-fatal (ERR NONFATAL), and error fatal (ERR FATAL). To supportinteroperability of agents which implement these messages, the followingrules can be used in one embodiment. Agents that generate PCI-e™ errormessages send error messages on the sideband message interface, andintegrated device fabric 30 receives error messages on the sidebandmessage interface and forwards them upstream on primary channel 49.Agents that implement PCI-e™ root ports receive error messages eitheracross the PCI-e™ link or on the downstream side primary channel ifimplemented as a virtual root port. Agents that implement a PCI-e™ rootcomplex event collector will receive error messages on the sidebandmessage interface. In other implementations such messages can be sent onthe primary interface.

The PCI-e™ error messages contain a requester ID (which may include busnumber, device, and function) and a message code. The PCI-e™specification indicates that non-function specific errors that occur atan endpoint are logged in every function, however only one error messageis sent for each enabled severity. For example, if all functions areprogrammed to treat the error as fatal, then only one fatal errormessage is sent, but if some functions are programmed to treat the erroras fatal and others are programmed to treat the error as non-fatal, thenone fatal and one non-fatal error message are sent. The following errorsmay be non-function specific: unsupported request (UR), when caused byno function claiming a transaction layer packet (TLP); unexpectedcompletion when caused by no function claiming a completion; malformedTLP; end CRC (ECRC) fail; receiver overflow; and flow control protocolerror. Note that in various embodiments, the last two are notapplicable. ECRC fail is optional and can only occur if ECRC checking isenabled.

It is the responsibility of error logic 40 d of the integrated devicefabric 30 to determine that a transaction results in a non-functionspecific error. On detection of a non-function specific error, the IDFwill assert a put with a non-specific error signal (cmd nfserr) to everydownstream agent that is a part of the integrated device. When an agentreceives a put with the cmd nfserr asserted, it logs the error but doesnot send any error message even if it is configured to send a message.MF logic 35 is responsible for sending the appropriate error messages. Asingle bit strap is used in the integrated function to know that it isconnected below an integrated device fabric.

MF logic 35 shadows the necessary bits from every function below theintegrated device fabric that indicates which severity error thefunction should report for that error. In one embodiment, a table may beprovided in error logic 40 d to indicate which bits are required. Theintegrated device fabric thus detects that the error has occurred andbroadcasts the TLP to all integrated functions below the integrateddevice fabric. The broadcast can be done with a simultaneous put, orsequential puts to all targets. The MF logic will then check the shadowcopies of the error configuration bits and send the correct errormessages upstream.

MF logic 35 may further include register shadow logic 40 a. If anyfunction in an agent implements PCI-e™ ARI capability, then they mustall implement ARI. Each integrated function that implements the ARIcapability implements a private maximum payload size register that isseparate from the PCI-e™ defined maximum payload size configurationregister, and a strap input to indicate if the integrated function isinstantiated in a root complex or outside a root complex. This registeris accessible from the sideband message interface. When the integratedfunction is strapped to indicate that it is outside of the root complex,then all functions with a function number other than zero ignore thePCI-e™ specification-defined maximum payload size register and use theprivate register for the maximum payload size value. It is theresponsibility of register shadow logic 40 a of MF logic 30 to shadowfunction's 0's maximum payload size value into the other agentsconnected to IDF 30. MF logic 35 may include other functions, in someembodiments. In one embodiment, each agent may send a latency messageover the sideband channel to the multi-function logic, which aggregatesmessages, takes the worst case latency number and sends it to thevirtual port for reporting upstream.

Referring now to FIG. 3, shown is a block diagram of a system-on-chip(SoC) in accordance with one embodiment of the present invention. Asshown in FIG. 3, SoC 200 may be a single die device that includesvarious entities that perform different functions. As shown in FIG. 3, aserver controller hub (SCH) 210 may provide an interface to a systemcontroller such as a central processing unit (CPU) or other mainprocessing entity. Via various settings, e.g., fuse select settings suchas fusible links represented by switches S1 and S2, may be controlled toenable coupling of different circuitry to SCH 210. As seen, switch S1may enable direct coupling of a virtual port 220, which may be a virtualroot port or a virtual switch port directly to SCH 210. When S1 connectsvirtual port 220 to SCH 210, virtual port 220 is a root port. In analternate configuration, virtual port 220 may couple directly to aswitch fabric (SWF) 270. When S1 connects virtual port 220 to SWF 270,it is a switch port. Switch S2 may be controlled to couple an integrateddevice fabric 230 to a storage controller unit (SCU) 260 or to disablesuch coupling.

As further shown in FIG. 3, IDF 230 may be coupled to an interface 240,which may provide an interface to various off-chip devices such asSMBUS, non-volatile SRAM, serial flash, and Ethernet. Still further, IDF230 may couple to a SCU 250 that also can couple to various off-chipdevices, such as disk drives or a SAS network. Still further, in a givenimplementation, switch S1 may enable direct coupling of virtual port 220to switch fabric 270, which in turn couples to one upstream switch port280 which may be coupled to downstream switch ports (not shown), whichcouple to an off-chip endpoint. SoC 200 may further include a design fortest (DFx) agent 290 to perform various design for test functions. Whileshown with this particular implementation in the embodiment of FIG. 3,the scope of the present invention is not limited in this regard.

Embodiments may further be implemented in a broader system context, suchas a PCIe™/PCI system. Referring now to FIG. 4, shown is a block diagramof a system 300 in accordance with an embodiment of the presentinvention. As shown in FIG. 4, system 300 may include various fabrics tocouple different types of functions and devices to upstream componentssuch as a main CPU and memory complex, represented by CPU 305. Whileshown as a single block, understand that CPU 305 may include one or moreCPUs and local memory, which may be implemented in a bridge or ringtopology, for example. CPU 305 couples to a root complex fabric 310.

Root complex 310 may denote the root of an IO hierarchy that connectsCPU 305 to the IO subsystem. As seen, various entities may be coupled toroot complex 310, including root complex integrated endpoints 312_(a)-312 _(n), root ports including a physical root port 314 and avirtual root port 330, and another such interface 313 which, in oneembodiment may be a DMI or DMIc interface. In the embodiment of FIG. 4,some of these interfaces and ports may couple off-die via cross-dieconnections 316 and 345, while virtual root port 330 may be integratedon-die to an integrated device fabric 335 that in turn is coupled to anintegrated PCIe™ endpoint 340 including one or more integrated functions341 _(a)-341 _(n). Thus, to the software executing on CPU 305, both rootport 314 and virtual root port 330 may appear as being coupled tooff-chip PCIe™ devices. Note that endpoints 312 _(a)-312 _(n) andfunctions 341 _(a)-341 _(n) are designed to the same rules such that asystem integrator can choose to instantiate an agent as either a RCintegrated endpoint or an integrated function without making changes tothe re-usable agent implementation.

Still further shown in FIG. 4, cross-die connection 316 may couple toanother interface 317 which in turn couples to a root complex fabric320, to which one or more root complex integrated endpoints 322 _(a)-322_(n) may be coupled.

Via cross-die connection 345, a PCIe™ multi-function device 350 may bepresent, which may also couple to a switch fabric 360 via a switch port352 and an integrated function 354. In turn, switch fabric 360 maycouple to various downstream ports including a switch port 365 andvirtual switch ports 368 _(a) and 368 _(b). These virtual switch portsmay couple to IDFs 370 and 375, each of which may include one or morePCI endpoints coupled thereto. In the embodiment shown in FIG. 4, aPCIe™ endpoint 372 may include an integrated function 373, and a PCIe™endpoint 380 may include integrated functions 383 _(a)-383 _(n). Whileshown with this particular implementation in the embodiment of FIG. 4,the scope of the present invention is not limited in this regard.

Referring now to FIG. 5, shown is a flow diagram of a method inaccordance with one embodiment of the present invention. As shown inFIG. 5, method 400 may be implemented in an integrated device fabric tohandle incoming messages from an upstream-connected device coupledthereto. As shown in FIG. 5, method 400 may be used for handlingincoming messages received from upstream components, such as a virtualport to which the IDF is coupled (block 410).

When received in the IDF, a message which may be a command, may bebroadcast to all downstream agents via a primary channel (block 420).Then the IDF may determine whether it receives a decode confirmationfrom one of the agents (diamond 430). That is, as discussed abovetransmission of messages downstream may occur in a two-phase processwhere the message is first broadcast to all agents, which perform theirown target decode. If the message is not intended for any of thedownstream components, an error message may be generated and sentupstream (block 435).

If instead a target confirmation is received from one of the agents,control passes to diamond 440 where it may be determined whether thetargeted agent has resources to handle the message (diamond 440). If so,control passes to block 450, where the message may be arbitrated withother messages for transmission downstream. Then at block 460 themessage may be sent to the targeted agent. Of course, other mechanismsfor handling received messages may be used in other embodiments. Forexample, as discussed above address decode may occur in the fabricitself in some implementations.

Referring now to FIG. 6, shown is a flow diagram of a method forhandling incoming messages from coupled agents. As shown in FIG. 6,method 500 may begin by receiving sideband messages from one or moreagents via a sideband channel (block 510). For example, incomingsideband messages may be provided to a sideband endpoint, which may bepart of multi-function logic of an integrated device fabric. Thisendpoint may route messages to an appropriate logic within themulti-function logic (block 520). For example, error messages may besent to error logic, power management messages sent to power managementlogic and so forth. The given logic may then process the receivedmessages (block 530). For example, as discussed above the logic mayperform an aggregation of multiple sideband messages to thus form anappropriate aggregated message for transmission upstream. Then, as shownin FIG. 6, the aggregated message may be forwarded upstream, e.g., to avirtual port via the primary channel (block 540).

Using embodiments of the present invention a standard solution can thusbe realized for implementing agents that can be used as either rootcomplex integrated devices or non-root complex integrated devices.Accordingly re-use of agents across various products can occur such thatagents of one or more vendors can be incorporated into a single dieintegrated circuit.

Note that embodiments provide for identical integration of an IP blockbelow a PCI-e™ switch, switch port, PCIe™ root port, or directly below aroot complex. In contrast, according to the PCI-e™ specification,switches are not allowed to integrate a device on an internal bus.(PCI-e™ specification language: “Endpoints (represented by Type 00hConfiguration Space headers) must not appear to configuration softwareon the Switch's internal bus as peers of the virtual PCI-to-PCI Bridgesrepresenting the Switch Downstream Ports.”). However, as shown in FIG. 4an IP block can be integrated as a function of an integrated device thatcontains a switch upstream port. In this case switch fabric 360 is asingle fabric that carries traffic for two logical PCI buses associatedwith the primary and secondary side of the upstream switch port virtualpeer-to-peer bridge.

Embodiments may also be fully PCI-e™ complaint, allowing agents designedto a standard interface to be used inside of a root complex or in anintegrated device. Also using an IDF having multi-function logic inaccordance with one embodiment of the present invention provides astandard way to handle interactions between agents such that agents fromdifferent providers can be connected together into a singlemulti-function device.

Embodiments may be implemented in code and may be stored on a storagemedium having stored thereon instructions which can be used to program asystem to perform the instructions. The storage medium may include, butis not limited to, any type of disk including floppy disks, opticaldisks, optical disks, solid state drives (SSDs), compact disk read-onlymemories (CD-ROMs), compact disk rewritables (CD-RWs), andmagneto-optical disks, semiconductor devices such as read-only memories(ROMs), random access memories (RAMs) such as dynamic random accessmemories (DRAMs), static random access memories (SRAMs), erasableprogrammable read-only memories (EPROMs), flash memories, electricallyerasable programmable read-only memories (EEPROMs), magnetic or opticalcards, or any other type of media suitable for storing electronicinstructions.

While the present invention has been described with respect to a limitednumber of embodiments, those skilled in the art will appreciate numerousmodifications and variations therefrom. It is intended that the appendedclaims cover all such modifications and variations as fall within thetrue spirit and scope of this present invention.

1. An apparatus comprising: a virtual port coupled between an upstreamfabric and an integrated device fabric, the virtual port including amaster interface to interface with the upstream fabric and a targetinterface to interface with the integrated device fabric; the integrateddevice fabric including a multi-function logic to handle interrupts,power management messages, and non-function specific error messages, theintegrated device fabric coupled to at least one intellectual property(IP) block and having a primary channel to communicate data and commandinformation between the at least one IP block and the virtual port and asideband channel to communicate sideband information between the atleast one IP block and the multi-function logic; and the at least one IPblock to perform a function, wherein the virtual port, the integrateddevice fabric and the IP block are adapted on a single semiconductordie.
 2. The apparatus of claim 1, wherein the integrated device fabriccouples to a transaction layer of the virtual port and a transactionlayer of the at least one IP block, without intervention of a link layeror a physical layer.
 3. The apparatus of claim 1, wherein themulti-function logic includes a sideband endpoint to communicate with asideband router via the sideband channel, the sideband router furthercoupled to the at least one IP block.
 4. The apparatus of claim 1,wherein the integrated device fabric further includes an arbiter toarbitrate messages along the primary channel from the virtual port to aplurality of IP blocks coupled to the integrated device fabric.
 5. Theapparatus of claim 4, wherein the multi-function logic includes a firstlogic to detect a non-function specific error message from the pluralityof IP blocks via the sideband channel and to generate an aggregatemessage for transmission to the virtual port via the primary channel. 6.The apparatus of claim 4, wherein the multi-function logic includes asecond logic to receive a power management message from the virtual portvia the primary channel and to generate a downstream power managementmessage to the plurality of IP blocks via the sideband channel.
 7. Theapparatus of claim 4, wherein the plurality of IP blocks areheterogeneous blocks and wherein the integrated device fabric is tostandardize communication between the heterogeneous blocks and thevirtual port.
 8. The apparatus of claim 5, wherein the integrated devicefabric and the plurality of IP blocks appear to software as a singlePeripheral Component Interconnect (PCI) endpoint coupled via a PCI link.9. The apparatus of claim 1, further comprising a first fusible link tocouple the integrated device fabric to a switch fabric via the virtualport, wherein the virtual port acts as a switch port when the firstfusible link is enabled, and a second fusible link to coupled to theintegrated device fabric to a hub agent via the virtual port, whereinthe virtual port acts as a root port when the second fusible link isenabled.
 10. A method comprising: coupling a virtual port between anupstream fabric and an integrated device fabric, the virtual portincluding a master interface to interface with the upstream fabric and atarget interface to interface with the integrated device fabric;handling interrupts, power management messages, and non-functionspecific error messages in a multi-function logic of the integrateddevice fabric, the integrated device fabric coupled to at least oneintellectual property (IP) block and having a primary channel tocommunicate data and command information between the at least one IPblock and the virtual port and a sideband channel to communicatesideband information between the at least one IP block and themulti-function logic; and performing a function using the at least oneIP block, wherein the virtual port, the integrated device fabric and theIP block are adapted on a single semiconductor die.
 11. The method ofclaim 10, further comprising arbitrating messages along the primarychannel from the virtual port to a plurality of IP blocks coupled to theintegrated device fabric.
 12. The method of claim 11, further comprisingdetecting, in a first logic of the multi-function logic, a non-functionspecific error message from the plurality of IP blocks via the sidebandchannel and generating an aggregate message for transmission to thevirtual port via the primary channel.
 13. The method of claim 12,further comprising, in a second logic of the multi-function logic,receiving a power management message from the virtual port via theprimary channel and generating a downstream power management message tothe plurality of IP blocks via the sideband channel.
 14. The method ofclaim 11, further comprising standardizing communication between theplurality of IP blocks and the virtual port, wherein the plurality of IPblocks are heterogeneous blocks.
 15. A system comprising: a processor; aroot complex fabric coupled to the processor; a root port coupled to theroot complex fabric; a multi-function device coupled between the rootport and an upstream fabric; a virtual port coupled between the upstreamfabric and an integrated device fabric, the virtual port including amaster interface to interface with the upstream fabric and a targetinterface to interface with the integrated device fabric; the integrateddevice fabric including a multi-function logic to handle interrupts,power management messages, and non-function specific error messages, theintegrated device fabric coupled to at least one intellectual property(IP) block and having a primary channel to communicate data and commandinformation between the at least one IP block and the virtual port and asideband channel to communicate sideband information between the atleast one IP block and the multi-function logic; and the at least one IPblock to perform a function, wherein the virtual port, the integrateddevice fabric and the IP block are adapted on a single semiconductordie.
 16. The system of claim 15, wherein the integrated device fabriccouples to a transaction layer of the virtual port and a transactionlayer of the at least one IP block, without intervention of a link layeror a physical layer.
 17. The system of claim 15, wherein themulti-function logic includes a sideband endpoint to communicate with asideband router via the sideband channel, the sideband router furthercoupled to the at least one IP block.
 18. The system of claim 15,wherein the integrated device fabric further includes an arbiter toarbitrate messages along the primary channel from the virtual port to aplurality of IP blocks coupled to the integrated device fabric.